COMP124

Device Manager

Monitors every device within the system
Ensures each process gets fair access to the devices it needs

The Device Manager:

• Keeps track of all devices connected to the system
• Creates virtual files that map onto physical devices
• Schedules read/write access to devices according to system policy
• Deals with multiple requests for the same device
• Communicates with devices during operation
• Provides standard system calls so other software can use devices
• Deallocates system resources when the devices are no longer needed (eg. unplugged)

Layers of Abstraction

• Program Code
• System Call Interface
• Device Driver
• Device
  • Device Controller
    • Memory
    • Registers
  • Mechanical/Electronic Hardware

Device Abstraction

Devices can be categorised by their behaviour

• Character vs Block
• Sequential vs Random
• Shared vs Dedicated
• Speed of operation
• Data direction (read-write, read-only, write-only)
  Device driver hides these differences from the kernel
• Kernel can treat devices as simple files or streams
• Same system calls can be used to access any device (to read/write data)
• For example, by accessing a file in the Linux /dev directory (virtual file system)
• Device driver sends data to device controller
• Device controller converts data into electronic signals to operate the hardware

Device Buses

External devices are called peripherals
Devices can be internal too, eg. soldered onto the motherboard
Others can be plugged into sockets or slots on the motherboard (via a daughterboard)

There a multiple buses designed for different purposes:

• PCIe - Peripheral Component Interconnect Express (general purpose)
• USB - Universal Serial Bus (general purpose)
• NVMe - Non-Volatile Memory Express (often called M.2) (flash disks (SSD))
• SATA - Serial AT Attachment (mechanical disks (HDD))

Each bus has its own protocol and format (and speed) for sending and receiving data

System Bus Connections

![[Pasted image 20250519025328.png]]

Communication

The device controller has several registers to pass commands and data to the device

• CPU might have special instructions to change and inspect these device registers
• Can also use the ioctl system call to communicate directly with the device controller
  Most operating systems implement memory-mapped I/O
• Virtual addresses in main memory are mapped on to device registers
• Allows CPU to use its standard instructions to manipulate device registers
• Device registers look and behave exactly like normal memory
  Another approach is port-mapped I/O
• Devices have a separate address space assigned by the CPU
• Dedicated instructions to move data between CPU registers and device addresses
• Often requires a separate bus for I/O or dedicated pins on the physical CPU

Device and Disk Scheduling

The device manager schedules I/O activities to maximise system performance

• Minimise time wasted by moving the HDD read/write head
• Prioritise I/O requests for particular processes
• Ensure disk access is shared equally between processes
• Guarantee that certain requests are met before a deadline (in real time systems)
• Minimise overall wait time for processes in the blocked state
  Each disk has an I/O wait queue, which the scheduler can reorder depending on policy
• First come first served
• Shortest seek first
• Elevator algorithm
• Completely fair queueing
• Anticipatory scheduling

Disk Block Scheduling

The scheduler tried efficiently to read/write disk blocks to minimise process wait time

• Completely fair queueing
  • Requests from each process are placed in their own queue
  • Queues are serviced via time slices according to process priority values
• Anticipatory scheduling
  • Processes might want to deal with data from disk before issuing another request
  • Normally other requests would be serviced during this gap in disk activity
  • However that would take the read/write head away from where it was
  • Anticipates further nearby requests by pausing for a short time (a few milliseconds)
• Elevator algorithm
  • Behaves like an elevator
  • Schedules block I/O in the order of travel of the read/write head
  • Only accesses a block when the head is moving in that direction

Buffering

For a program that for example reads characters from a file one by one

• Accessing the disk for each read request is costly
• Device manager needs to liaise with file manager to access file on disk
• Disk head (HDD) needs to physically move for each read request
  A more efficient method is to set up an area of memory called a buffer
• First read request reads a whole chunk of data into the buffer
• Subsequent requests read from the buffer instead of the disk
• Only need to involve the disk again when the buffer empties
  This is also used when writing to files (and other devices)
• Put each character into the buffer and write in one operation when buffer is full
• Danger of losing data, so program can use fflush system call to write the buffer

The system could use double buffering

• One buffer to read/write data while another is being filled/emptied
• Swap between them to maximise efficiency
  Buffering can happen at multiple places in the device abstraction
• Software programs
• Library subroutines
• Operating system
• Hardware (eg. memory buffer built into disk drive)
  Buffering can cause inconsistency issues
• Data physically on disk doesn't match what the system thinks it wrote
• Important to flush buffers regularly via system call or timer inside device controller

Spooling

Some devices are non-shareable

• For example, a printer can only print one document at once
• Even if it is on a network and available to lots of systems
  These devices use a daemon process called a spooler
• Imagine spooling tape from a reel
• Backronym: simultaneous peripheral operations on a line (SPOOL)
  Processes send their data to the spooler daemon
• Spooler creates a temporary file for each process
• Process writes data into the file
• No need to worry about availability of device (file will always be available)
• Spooler sends data to actual device when it becomes free (de-spooling)

Direct Memory Access

Hardware devices can access main memory independently of the CPU

• Known as direct memory access (DMA)
• The CPU initiates the data operation (read/write)
• Can continue to run other processes while the data transfer takes place
• Will receive an interrupt when the transfer is complete
  Overall system performance can be maximised by bypassing the CPU
• Many devices, eg. disks, are much slower than the CPU
• System bus is still tied up during the transfer
• CPU can be getting on with things that don't require access to the bus

DMA Controller

The DMA controller has its own registers (MAR, byte counter, control register)

• CPU loads the registers with the device address and details of transfer
• DMA controller carries out the data transfer in the background
• Transfer happens via system bus in burst, cycle-stealing or transparent mode
  ![[Pasted image 20250519042301.png]]

Devices in Linux

Linux creates a virtual file within the /dev directory for each device in the system

• Devices appear to be simple files or streams
• Allows programmatic access via standard file handling system calls
• Device driver requests an entry in the file system when device is enabled
• Linux uses the devtmpfs virtual disk format with the udev device manager

Some pseudo devices are also created

Device files start with certain letters to show what type of device they are

• lp - printer
• sd - disk
• pp - parallel port
• tty - terminal
• pty - pseudo-terminal (pips between processes)
• and many more